@dpwdec hey, I noticed you introduced versioning for binding. The thing is that bindings atm should be aligned with spec, which means only the latest binding version should be in master. We are not extending AsyncAPI v2 any further, so should be with bindings for v2. So they should not be in master. In other words, current master should only store latest, which is v3

@dpwdec hey, I noticed you introduced versioning for binding. The thing is that bindings atm should be aligned with spec, which means only the latest binding version should be in master. We are not extending AsyncAPI v2 any further, so should be with bindings for v2. So they should not be in master. In other words, current master should only store latest, which is v3

Whilst we are not extending AsyncAPI v2 any further, I don't think we necessarily want to ask folks to upgrade to V2 just to get fixes or extensions to a binding for a given provider. The upgrade to V3 might take some time for some users. I would agree that master should be V3 and that V2 should be the branch however

I get your point. We had the same convo for Kafka binding. Afaik it was around v3 release date. Till today there were no complaints that people need updates to v2 bindings

If we keep supporting v2, people are not motivated to move to v3. As org we do all we can to motivate to migrate, converters and other tools support it already, and supported them on release date.

If in bindings we wanna go away from that model, then imho it could be a decision all binding owners agree with, so we are consistent. But my recommendation is to really consider it, be worried about it only if there is really a request coming from the community to add something to v2 binding, and that it is critical and there is no other way to do it.

Once we let in v2 support for one binding, it is opening door for precedence to do it for other bindings, and event the spec, and you know EDA and AsyncAPI maintenance is complex enough with one version in place 😅

And in the end, if one day, we see there is a really critical reason to improve some v2 binding, then it can be done as "one-time-exception" with some dedicated branch/tag and clear story in issue/PR why we had to do it.

@dpwdec @iancooper thoughts?

@dpwdec @iancooper thoughts?

As AsyncAPI moves forward, it will have to accept that users will lag behind the latest version of the specification. Adoption has some dependency on support for earlier versions. Now, admittedly, we are towards the start of this journey, but where folks have tooling built against V2, we will break them if we don't retain compatibility with it.

So, at JET, we have tooling that uses V2. We can't shift all those folks over to V3 overnight. There are many endpoints, and even if we automated the process of converting their scripts, the review process would take weeks, and involve a lot of sign-offs. That would likely lead us to fork, so that we could maintain V2.

So I think we need a policy here. A typical one is to support the current release, and one release earlier.

The problem then becomes, do we match bindings version to AsyncAPI version? I think for sanity yes, so we have V2 bindings for V2 and V3 for V3 etc. Now, I would caveat that. I would ensure that once V3 is out, V2 only gets additive, non-breaking changes. So you can't change the binding for V2 in a non-backwards compatible way. That is because, the only reason to have V2 is backwards compatibility, and if a new release of the middleware comes out, whilst you are still on V2, just upgrade your AsyncAPI to V3

But that also means that in V3 we might need to have breaking changes. That is because we might find that the API for middleware changes in a fashion that is not backwards compatible. We might have to use a non-SemVer approach at that point and use V3.X where X is a breaking change.

It is a slightly different painpoint than with OpenAPI, because it does not need to version.

BTW, I am not sure if we need to communicate binding version in the binding specification. I suspect that is mostly out-of-band, but not really thought that through @dpwdec ?

As AsyncAPI moves forward, it will have to accept that users will lag behind the latest version of the specification

100%, I don't think anybody really thinks people always move to latest ASAP, even though we provide proper conversion solutions.

Now, admittedly, we are towards the start of this journey, but where folks have tooling built against V2, we will break them if we don't retain compatibility with it.

Tooling is a bit different thing. We still have tools, like parser, generator and many others that support v2 and provide bug fixes there. So nobody here is saying: stop using tools for v2 - just at the moment the message is, if you want new features that are not yet in the spec, add them to new spec or new spec binding and support this new spec feature in the tool, then just make sure you migrate to new spec. If someone can switch to using a newer binding version, why not switch to a newer spec version?

So I think we need a policy here. A typical one is to support the current release, and one release earlier.

100% as we already had this discussion in the case of kafka for v3: #182
We talked about tagging there as well. Interesting is to notice that November 2023 there were worries about v2 support, slow adoption and all that stuff - 11month later, nothing bad really happened. This is why the best way for backward compatibility and any updates is to do these in a separate v2 tag - to show that any of these things are special cases and are discouraged.

So yeah, please make sure master reflects v3 and open a separate discussion where we can ping everyone, all codeowners to participate and get a consensus that we can document and follow